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Abstract _ ‘ _ 

A  critical  factor  in  the  U.S.  Army  Research  Laboratory’s  (ARL)  strategy  to  do  more  with  less 
resources  is  the  automation  of  a  single,  ARL- wide  purchasing  process.  This  report  describes  the 
initial  plan  for  developing  the  Buylt  Prototype,  a  software  prototype  for  an  automated  purchasing 
system  that  provides  an  electronic  workflow  for  ARL  purchasing  processes  and  interfaces  with 
standard  Department  of  Defense  (DOD)  systems  required  by  those  processes.  The  Buylt 
Prototype  is  the  first  component  of  the  Corporate  Business  Application  Software  System 
(C-BASS),  a  suite  of  integrated  online  transaction  process  software  products  that  will  provide 
Corporate  business  functions  electronically  throughout  the  ARL  enterprise.  C-BASS  is  a 
cornerstone  of  the  new  ARL  Enterprise  Information  Technology  Architecture  developed  in  1997 
by  the  Enterprise  Systems  Division.  This  report  provides  a  statement  of  the  problem  to  be  solved 
by  the  Buylt  Software,  the  technical  and  management  approaches  to  be  used,  and  a  detailed 
project  schedule. 
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1.  Introduction 


1.1  Identification.  This  report  covers  the  plan  for  the  development  of  Buylt  for  use  at  the 
U.S.  Army  Research  Laboratory  (ARL)  Adelphi  Laboratory  Center  (ALC).  This  plan  defines 
work  that  was  begun  in  January  1997.  Planning  charts  and  activities  described  in  the  plan  refer 
to  the  actual  dates  on  which  these  project  events  were  expected  to  occur. 

The  Buylt  Prototype  forms  the  nucleus  of  Buylt  Version  1.0  for  use  at  ALC  as  a  fall 
production  system.  Buylt  is  a  component  of  the  Corporate  Business  Application  Software 
System  (C-BASS)  family  of  applications,  an  integrated  family  of  Notes  and  Web-based  software 
to  support  ARL  electronic  workflow  and  task  automation.  This  suite  of  applications  interfaces 
with  standard  DOD  systems  to  provide  functionality  unique  to  research  and  development  (R&D) 
competencies. 

1.2  Purpose.  The  purpose  of  the  Buylt  Prototype  is  to  experimentally  model  a  secure 
client/server  system  that  will  provide  for  the  automated  routing,  approval,  tracking,  and  reporting 
of  small  purchase  requests  as  part  of  the  ARL  Intranet.  The  proof-of-concept  prototype  is  useful 
to  mitigate  risks  by  resolving  unknowns  related  to  new  technologies  being  used  to  build  the  ARL 
Intranet  architecture  and  to  refine  user  requirements  described  by  the  Business  Process 
Reengineering  (BPR)  ‘To-Be  Model”  [1]. 

1.3  Background.  Initiation  of  this  work  is  motivated  by  ARL  downsizing  and  findings  of 
the  ARL  BPR  report  on  the  small  purchase  process.  It  is  the  first  business  computing  application 
identified  for  implementation  as  part  of  the  new  ARL  Intranet. 

ALC  has  been  identified  as  the  site  with  the  most  critical  need  for  automated  small  purchase 
capability  because  it  has  had  major  reductions  in  purchasing  staff  and  currently  has  no  automated 
purchasing  tools.  The  BPR  “To-Be  Model:  Small  Purchase”  [1]  identifies  potential  process 
improvements,  some  of  which  require  computer-aided  automation  to  increase  efficiency  of 
purchasing  operations  in  ARL. 
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The  full  Buylt  Application  System  will  implement  a  secure  ARL-wide  client/server  system 
that  allows  users  to: 

(1)  Request  small  purchases  electronically, 

(2)  Route  the  request  to  the  necessary  functional  users  for  electronic  approval, 

(3)  Automate  interfaces  to  necessary  standard  legacy  systems,  and 

(4)  Provide  tracking  and  reporting  and  travel  request  status. 

Buylt  will  conform  to  the  Enterprise  Systems  Division  (ESD)  life-cycle  strategy  for  ARL 
Intranet  application  development.  Development  will  be  performed  in  phases,  using  an 
incremental,  evolutionary  approach.  The  first  deliverable  will  be  the  Buylt  Prototype  described 
in  this  plan. 


The  prototype  will  provide  end-to-end  functionality  with  scaled-down  capabilities  and  will 
be  usable  only  at  ALC. 

1.4  Organizational  Responsibilities.  The  ARL  Corporate  Information  and  Computing 
Center  (CICC)  ESD  has  the  responsibility  to  develop  the  Buylt  plan  and  system  for  all  ARL 
sites.  The  Acting  Chief  of  ESD  is  Dr.  Dana  Ulery. 

1.4.1  Personnel  Requirement.  The  prototype  project  team  requires  personnel  from  ESD, 
the  Computing  Support  Branch  (CSB)  of  CICC’s  Automation  Resources  Division,  the  Chief  of 
Staff  (COS)  Procurement  Office,  and  an  outside  contractor.  Table  1  lists  the  project  personnel 
and  their  responsibilities. 

1.4.2  Interfacing  Groups.  The  Buylt  project  requires  interfacing  to  user  groups  and  to  the 
CICC  Advisory  Committee.  Buylt  users  include  COS  personnel  in  procurement,  budget,  and 
logistics  as  well  as  scientists,  engineers,  managers,  and  administrative  personnel  at  ALC  who 
purchase  items  in  this  category. 
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Table  1.  Project  Personnel 


Name 

ESS 

% 

Responsibility 

Wade  Jemigan 

ESD 

75 

Coleader,  Development,  Documentation 

Brian  Schallhom 

ESD 

75 

Coleader,  Development,  Documentation 

Janet  David 

ESD 

60 

Testing,  Documentation,  CM,  Metrics 

John  Leopard 

ESD 

100 

Development,  Documentation 

Wendy  McCoy 

ESD 

100 

Development,  Testing 

Sr.  Notes  Developer  (Contractor) 

ProVar 

100 

Development,  Documentation 

Pam  Stuecklen 

CSB 

10 

Lotus  Notes  System  Administration 

Debbie  Baggett 

COS 

5 

User  Requirements 

Timely  responsiveness  of  interface  groups  is  critical  to  meeting  the  schedule  for  this  project. 
Interface  groups  and  the  roles  they  play  relative  to  this  project  are  listed  in  Table  2. 


Table  2.  Interfacing  Groups 


Group 

Org. 

Role 

Business  Analysts 

COS 

Budget,  Logistics,  and  Procurement 
process  and  data  requirements 

Standard  Operations  and  Maintenance 
Army  Research  Development  System 
(SOMARDS)  User 

COS 

SOMARDS  interface  j 

Standard  Army  Automated  Contracting 
System  (SAACONS)  User _ 

COS 

SAACONS  interface 

CICC  Advisory  Committee 

CICC,  Director’s 
office,  COS, 
directorates 

User  requirements,  business 
direction 

2.  Statement  of  Problem 


The  prototype’s  key  requirements  are  to  provide  the  following  automated  functionalities: 

(1)  Routing,  approval,  tracking,  and  reporting  of  small-purchase  requests, 

(2)  Funds  certification  through  a  SOMARDS  interface,  and 

(3)  Upload  of  purchase  request  information  into  SAACONS. 
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Development  of  Buylt  Version  1  for  full  production  use  will  be  based  on  an  evolutionary 
development  approach  that  uses  the  Zachman  architectural  framework  and  an  iterative, 
incremental  life-cycle  model  [2,  3].  Buylt  Prototype  Release  1  is  the  first  intermediate  product 
that  will  be  developed  on  the  path  to  developing  Buylt  Version  1. 

Four  steps,  each  characterized  by  specific  activities  and  the  products  produced  by  those 
activities,  will  be  used  to  develop  the  prototype  [4]: 

(1)  Software  requirements  analysis, 

(2)  Design  analysis, 

(3)  Implementation,  and 

(4)  System  testing. 

Deliverables  will  include: 

(1)  Prototype  software, 

(2)  Prototype  structured  specifications  document, 

(3)  Prototype  testing  plans,  and 

(4)  Prototype  user  information  sheet. 

Intermediate  software  components  produced  to  demonstrate  specific  functions  will  include: 

(1)  Routing  and  tracking  function, 

(2)  Link  to  legacy  systems,  and 

(3)  Reporting  function. 


The  documents  will  provide  precise,  detailed  technical  models  and  processes,  rather  than 
ambiguous  English-language  descriptive  text.  They  will  be  appropriately  brief  and,  like  the 
prototype  software,  form  the  nucleus  for  full  system  documentation  [5]. 
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3.  Technical  Approach 


3.1  Life-Cycle  Strategy.  The  life-cycle  approach  being  used  stresses  three  principles: 

(1)  An  architectural  framework  that  explicitly  defines  critical  system  components  from 
multiple  perspectives  and  the  relationships  among  these  components  in  order  to  ensure 
integration  of  the  business,  operational,  and  computing  models  [6,  7]; 

(2)  Use  of  commercial-off-the-shelf  products  wherever  possible  to  reduce  costs  and  improve 
reliability  and  productivity  [6, 7],  and 

(3)  Evolutionary,  iterative  steps  to  incrementally  build  multiple,  shorter-cycle  products  and 
control  risk  [6, 7]. 

The  prototype  is  the  first  phase  in  the  life  cycle  of  the  full  production  product. 

3.2  Assumptions  and  Constraints.  Some  of  the  key  assumptions  and  constraints  are  shown 
in  Tables  3  and  4,  but  the  lists  are  not  all-inclusive. 

3.3  Anticipated  and  Unresolved  Problems.  Table  5  lists  some  of  the  anticipated  and 
unresolved  problems  that  could  affect  the  prototype  development  and  delivery. 

3.4  Development  Environment.  The  development  environment  will  consist  of: 

•  Hardware 

-  Server:  PC,  dual  133-MHz  Pentium  processors,  96  MB  RAM,  (2)  4.5-GB  hard  drives, 
4X  CD-ROM,  4-GB  4-mm  tape  drive,  ethemet. 

-  Client  development:  PCs,  Pentium. 
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Table  3.  Prototype  Assumptions 


Assumption 


13  January  1997  - 
Project  Start  Date 


Prototype  will  not  be  used 
for  critical  operations 


Explanation  


Requires  that  the  ALC  Lotus  Notes  development  server  is 
installed,  tested,  and  operational  by  that  date.  If  not,  start  date 
must  be  delayed  until  these  conditions  are  satisfied. _ 


Will  be  based  primarily  on  the  BPR  “To-Be  Model.” 


Prototypes  are  experimental  models  lacking  the  completeness  and 
robustness  of  full  production  systems. 


Table  4.  Prototype  Constraints 


Constraint 

Explanation 

Incomplete  user 
requirements  analysis 

Details  of  user  requirements  needed  for  software  analysis  will  not  be 
done  for  prototype. 

ALC  site  only 

Practices  differ  among  sites,  limiting  complexity  of  business  model. 

Single  product 
category 

The  requester  may  only  purchase  items  that  either  (1)  require  no  special 
approvals  or  (2)  require  special  approval  through  only  one  designated 
office  (TBD).  This  simplifies  the  automated  special  approval  process. 

Single  vender  per 
request 

The  requester  may  enter  three  suggested  vendors,  but  they  must  be  for 
all  the  items  on  the  request.  Separate  items  may  not  go  to  separate 
vendors.  Simplifies  the  interface  to  SAACONS. 

All  requests  must  go  through  the  foil  procurement  cycle.  Procurement 
buyers  may  use  credit  cards. 

Table  5.  Anticipated  and  Unresolved  Problems 


Problem 

Details 

Skill  gaps 

Project  developers  from  ESD  have  very  limited  Lotus  Notes 
experience  and  few  software  engineering  skills. 

Personnel  from  Systems  Operations  Branch  (SOB)  have  very  limited 
experience  administering  Lotus  Notes. 

Hardware 

•  New  Lotus  Notes  servers  not  folly  tested  in  ARL  development 
environment. 

•  New  development  client  hardware  required  for  this  project  not  yet 
tested  in  ARL  development  environment. 

Legacy  systems 

•  Need  for  middleware  products  between  Notes  and  the  legacy 
systems  (SOMARDS  and  SAACONS)  not  yet  resolved. 

•  SOMARDS  function  is  moving  to  Rock  Island,  IL,  severely 
restricting  ARL  access  to  SOMARDS  systems  personnel  necessary 
to  support  any  special  input/output  (I/O)  or  interface  needs. 
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Software 


-  Server:  Microsoft  Windows  NT  Server  v4.0  w/Lotus  Notes  Server  v4.5. 

-  Client  development:  Microsoft  Windows  95  or  NT  Workstation  v4.0  w/Lotus  Notes 
Desktop  v4.5. 

-  Middleware  between  Lotus  Notes  and  the  legacy  system  (TBD). 


3.5  Activities,  Tools,  and  Products.  Table  6  lists  the  major  activities,  methodologies,  and 
tools  to  be  used  and  the  products  of  each  phase  during  the  prototype  development  cycle. 


Table  6.  Major  Activities,  Methodologies,  and  Products 


Methodology/Tools  Products  1 

Software  Requirements 
Analysis 

Structured  analysis  [4] 

•  Data  flow  model 

•  Data  model 

•  Structured  specifications 
document 

Design  Analysis 

Structured  design  [8, 5] 

•  Legacy  interfaces 

•  Forms  design 

•  Navigators  design 

•  Structure  charts 

Implementation 

Lotus  Notes  application 
development  [9] 

•  Routing  and  tracking  function 

•  Link  to  legacy  systems 

•  Reporting  function 

•  Prototype  software 

System  Testing 

•  Software  engineering  testing 
methods  and  tools 

•  Configuration  management 

•  Prototype  test  plan 

•  Inspection  summaries 

•  Test  logs 

•  Discrepancy  reports 

•  Configuration  management 
controls 

4.  Management  Approach 

4.1  Assumptions  and  Constraints.  Lack  of  experience  with  Lotus  Notes  application 
development  and  the  new  C-BASS  computing  environment  combine  to  maximize  the  software 
engineering  complexity  rating  for  this  project.  The  less  than  2  years  of  experience,  on  average, 
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with  the  project  technologies  increases  the  uncertainty  of  effort  estimate  by  a  factor  greater 
than  2. 

This  circumstance  also  is  reflected  in  the  projected  schedule  of  activities  and  milestones.  For 
example,  training  will  have  a  high  priority  during  the  initial  stages  of  the  project. 

Factors  of  resource  scheduling  also  impact  the  development  timeline  given  in  this  report. 
While  the  Buylt  Prototype  has  a  high  priority  for  ESD,  it  must  compete  with  other  high-priority 
tasks  associated  with  establishing  the  ARL  Intranet.  Three  project  personnel  from  ESD, 
including  both  coleaders,  are  responsible  for  and  are  working  on  other  assignments  in  parallel 
with  their  work  on  this  project. 

4.2  Resource  Requirements.  Estimates  of  the  distribution  of  time  schedule  and  effort  over 
the  development  phases  are  listed  in  Table  7.  Estimates  of  formal  training  requirements  for 
project  team  members  are  shown  in  Table  8. 


Table  7.  Distribution  of  Time  Schedule  and  Effort  Over  Phases 


Phase 

Time  Schedule 
(%) 

Effort 

(%) 

Software  Requirements  Analysis 

15 

12 

Design  Analysis 

25 

33 

Implementation 

45 

40 

15 

15 

Table  8.  Project  Team  Training  Requirements 


Course 

Time  Schedule 
(%) 

Lotus  Notes  Application  Dev.  II 

5 

3 

Advanced  Lotus  Notes 

3 

1.5 
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4.3  Milestones  and  Schedules.  Appendix  A  gives  the  detailed  schedule  for  this  project, 
showing  work  breakdowns,  task  duration,  start  and  end  dates,  task  dependencies,  and  milestones 
(based  on  the  received  guidance  for  the  project  start).  Significant  milestones  include: 

•  Installing  the  hardware  and  software  making  up  the  development  environment, 

•  Completing  software  requirements  analysis, 

•  Defining  system  architecture,  data  description,  user  interface,  and  processing  actions, 

•  Implementing  software  designs  and  link  to  legacy  system,  and 

•  Bench-testing  and  field-testing  the  prototype. 

4.4  Metrics.  Metrics  will  be  used  to  monitor  and  manage  progress  and  product  quality. 
Both  objective  and  subjective  data  will  be  used  to  get  a  picture  of  project  status.  Key  project 
metrics  and  their  uses  are  listed  in  Table  9. 


Table  9.  Key  Project  Metrics 


Metric 

Use 

Development  task  status 

Weekly 

Progress,  process  control,  design 
stability 

Changes  (to  specs,  design) 

Biweekly 

Quality  of  specs,  design;  identify 
need  to  iterate  an  earlier  phase 

Software  size  estimates 

Biweekly 

Progress;  quality  of  process  and 
design 

Tests 

Weekly 

Progress;  quality  of  software,  design 

4.5  Risk  Management  The  primary  tool  for  managing  risk  is  the  use  of  disciplined 
software  engineering  approaches  and  methods  [6,  7].  As  mentioned  elsewhere  in  this  plan,  the 
use  of  multiple  new  technologies  coupled  with  an  inexperienced  staff  makes  this  a  project 
subject  to  risk.  The  detailed  technical  models  being  developed  in  all  phases  of  the  project 
provide  a  basis  for  assessing  technical  risk.  Potentially  high-risk  conditions,  whether  technical 
or  nontechnical,  will  be  identified  promptly  and  brought  to  the  attention  of  the  managers 
responsible  for  decisions  regarding  project  resources  and  timing. 
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5.  Product  Assurance 


5.1  Assumptions  and  Constraints.  The  Buylt  Prototype  is  a  proof-of-concept  model  and  is 
not  intended  for  use  in  a  production  environment  or  as  a  tool  to  replace  a  critical  manual  system. 


5.2  Quality  Assurance.  Monthly  2-hour  reviews  will  be  held  at  ALC  with  management 
from  CICC,  COS,  and  the  CICC  Advisory  Committee  to  assess  the  condition  of  the  project.  The 
reviews  will  provide  regularly  scheduled  monitoring  of  project  status.  They  will  address  quality 
assurance  by  examining  the  plans,  milestones,  and  intermediate  products  associated  with  the 
development  process. 

The  first  review  is  scheduled  for  the  morning  of  4  February  1997,  subject  to  the  13  January 
starting  date. 

5.3  Configuration  Management.  Standard  Configuration  Management  (CM)  methodology 
will  be  used  to  control  changes  to  system  products.  The  following  list  gives  the  prototype 
products  that  will  be  under  CM  control: 

(1)  Product  Software, 

(2)  Software  Development  Plan, 

(3)  Software  Requirements  Analysis  Document, 

(4)  Data  Flow  Model, 

(5)  Data  Model, 

(6)  Design  Document, 

(7)  Test  Plan,  and 

(8)  Test  Reports. 
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Milestone  ^  Rolled  Up  Milestone 


NO.  OF 

COPIES  ORGANIZATION 

2  DEFENSE  TECHNICAL 
INFORMATION  CENTER 
DTIC  DDA 

8725  JOHN  J  KINGMAN  RD 
STE  0944 

FT  BELVOIR  VA  22060-6218 

1  HQDA 

DAMO  FDQ 
D  SCHMIDT 
400  ARMY  PENTAGON 
WASHINGTON  DC  20310-0460 

1  OSD 

OUSD(A&T)/ODDDR&E(R) 
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